Session initiation protocol (sip) message incorporating a multi-purpose internet mail extension (mime) media type for describing the content and format of information included in the sip message

ABSTRACT

A system and method for processing a plurality of requests for multi-media services received at a call control element (CCE) defined on the system from a plurality of IP-communication devices. The system includes at least one Network Routing Element (NRE), a Service Broker (SB), a media sever, a plurality of application servers (ASs) and a plurality of border elements, all of which are coupled to the CCE. The CCE is adapted to receive requests for multi-media services and to generate subsequent requests for the multi-media services, which are communicated to the SB for processing. The subsequent requests can each include a Session Initiation Protocol (SIP) message including a message identifier portion having at least a first predetermined information field and a second predetermined information field. The message identifier portion of the SIP message declares the content and format of the SIP message to a recipient device defined on the system.

This application is a continuation of U.S. patent application Ser. No.11/971,024, filed Jan. 8, 2008, which is currently allowed and which isa continuation of U.S. patent application Ser. No. 10/324,198, (now U.S.Pat. No. 7,330,483) filed Dec. 19, 2002, both of which are incorporatedin their entirety herein.

FIELD OF THE INVENTION

The present invention relates generally to a SIP message including aMIME media type field and MIME media subtype field and, morespecifically, to SIP message including a MIME media type field and MIMEmedia subtype field that describes the content and format of informationincluded in the SIP message, which can be communicated between corenetwork elements defined on a multi-media service provider system.

BACKGROUND

Service providers, such as AT&T, can receive a number of requests fromvarious users of communication devices for any one or more of aplurality of multi-media service offerings. These requests may bedirected to a predetermined application server of a plurality ofapplication servers associated with the service provider, which isadapted to provide feature processing for the requested multi-mediaservice. As Service providers continue to add multi-media serviceofferings and corresponding application servers for providing featureprocessing for each of the requested multi-media services, there is aneed for improving communications between core network elements definedon the service provider system to permit more efficient and accurateprocessing of user requests for multi-media services.

SUMMARY OF THE INVENTION

A system for processing multi-media service requests to form amulti-media communication path between at least a first communicationdevice and at least a second communication device of a plurality ofcommunication devices. The system includes a call control element thatis adapted to receive at least a first request message for at least onemulti-media service from the first communication device. The callcontrol element is further adapted to process the first request messageto generate a second request message for the at least one multi-mediaservice. The second request includes a message identifier portion, whichhas at least a first predetermined information field and a secondpredetermined information field. The message identifier portion of thesecond request message enables a recipient network element to identifythe format and content of the second request message in relation toadvanced intelligent services. The recipient network element can includea number of elements included on the system, such as one or moreapplication servers or border elements.

In one aspect, the message identifier portion can include a Content-Typeheader portion. Further, the first predetermined information field ofthe Content-Type header portion can include a Multi-Purpose InternetMail Extension (MIME) Media Type field and the second predeterminedinformation field of the Content-Type header portion can include a MIMEMedia Subtype field.

In another aspect, the Content-Type header portion can include theparameters: Content-Type:application/vnd.att-advanced-intelligent-services;boundary=“--att-advanced services--.” In another aspect, theContent-Type header portion can include the parameters: Content-Type:application/vnd.att-advanced-intelligent-services; charset=US-ASCII;boundary=“--att-advanced-services--”.

In another aspect, the MIME Media Type field can include the parameters:application/sdp. Alternatively, the MIME Media Type field can includethe parameters: vnd.att-application/advanced-intelligent-features. Inone aspect, the MIME Media Subtype field can include the parameters:vnd.att-advanced-intelligent-features.

In another aspect of the present invention, a Session InitiationProtocol (SIP) message is set forth, which includes a Content-Typeportion having a MIME Media Type field and a MIME Media Subtype field.The MIME Media Type field declares a data type associated with the SIPmessage. The MIME Media Subtype field specifies a format for the datatype that allows a predetermined recipient network element, whichreceives the SIP message, to identify the format and content of the SIPmessage in relation to advanced intelligent services. The SIP messagecan include at least one of a SIP Redirect message, a SIP INFO message,a SIP UPDATE message or a SIP BYE message.

In another aspect of the present invention, a method of processingmulti-media service requests received at a multi-media services providersystem is set forth to form a multi-media communication path between atleast a first communication device and at least a second communicationdevice of a plurality of communication devices. The method includesreceiving at least a first request message for at least one multi-mediaservice at a call control element located on the multi-media servicesprovider system. The first request message is processed at the callcontrol element for generating a second request message for the at leastone multi-media service. The second request message includes a messagecontent identifier portion having at least a first predeterminedinformation field and a second predetermined information field.

In one aspect, the method further includes processing the second requestmessage at a service broker element located on the multi-media servicesprovider system to identify a format and content of the second requestmessage. For example, identifying the format and content of the secondrequest message includes identifying advanced intelligent servicesrequested by the second request message.

In another aspect, the method includes receiving the first requestmessage for the at least one multi-media service at an applicationserver located on the multi-media services provider system. The firstrequest message is processed at the application server to identifyadvanced intelligent services associated with the first request message.

In another aspect, generating the second request message at the callcontrol element, which includes the message content identifier portion,includes generating a Session Initiation Protocol (SIP) INVITE messageand including a Content-Type field.

BRIEF DESCRIPTION OF THE DRAWING

The foregoing and other objects of this invention, the various featuresthereof, as well as the invention itself, can be more fully understoodfrom the following description, when read together with the accompanyingdrawings in which:

FIG. 1 is an exemplary high-level schematic block diagram of a systemfor providing multi-media communications between a plurality ofcommunication devices according to the present invention;

FIG. 2 is an expanded schematic block diagram of the system shown inFIG. 1; and

FIG. 3 is a high level flow chart illustrating process steps executableon the system of FIG. 2.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 shows one embodiment of a communication network 10 for providingmulti-media communications between at least first 22 a and second 22 bcommunication devices of a plurality of communication devices, inaccordance with the present invention. The communication network 10includes a multi-media provider system 10 a, which is operative toprovide a plurality of multi-media services to the first 22 a and second22 b communication devices, via respective first 34 a and second 34 bSIP-enabled IP-Private Branch Exchanges (hereinafter referred to as“PBXs”). It should be understood that the multi-media services providersystem 10 a is additionally operative to provide a plurality ofmulti-media services to a plurality of other communication devices notspecifically shown herein.

Referring to FIG. 2, in the exemplary embodiment, the multi-mediaservices provider system 10 a includes a centrally located Call ControlElement 24 (CCE), at least one Media Server (MS) 30, a plurality ofApplication Servers (ASs) 32 a, 32 b, 32 c (collectively referred tohereinafter as ASs 32 a-32 b), at least one Network Routing Engine (NRE)33, at least one Service Broker (SB) 36 and a plurality of BorderElements (BEs) 26 a, 26 b, 26 c, 26 d (collectively referred tohereinafter as BEs 26 a-26 d). The CCE 24 is coupled to the plurality ofASs 32 a-32 c and to the plurality of BEs 26 a-26 d. The CCE is furthercoupled to the MS 30, the NRE 33 and the SB 36. Although not shown, theBEs 26 a-26 d can also be coupled directly to one or more of the ASs 32a-32 b.

In the exemplary embodiment, the BE 26 d is coupled to the first PBX 34a and the BE 26 b is coupled to the second PBX 34 b. Further, the BE 26c is coupled to PBX 34 c, via an access gateway 31, and is adapted foroperation using an H.323 format. It should be understood that the BEs 26a-26 d can be coupled to a plurality of other PBXs (not shown), whichare included in other embodiments not specifically shown herein.

In the exemplary embodiment, the first PBX 34 a is coupled to the firstcommunication device 22 a. Further, the second PBX 34 b is similarlycoupled to the second communication device 22 b.

The CCE 24, for example, can be provided by Lucent Corporation of MurrayHill, N.J. The CCE 24 may be defined as a back-to-back user agent(B2BUA), which operates to receive a plurality of INVITE messages fromany one of the plurality of BEs 26 a-26 d and upon receipt of theplurality of INVITE messages from the BEs 26 a-26 d, the CCE 24 caninitiate an equal plurality of INVITE messages to the SB 36. The CCE 24is further adapted to receive a plurality of Redirect messages from theSB 36 in response to the plurality of INVITE messages sent to the SB 36from the CCE 24. When the CCE 24 receives a Redirect message back fromthe SB 36 in response to an INVITE message and depending on instructionsprovided by the SB 36 in the Redirect message, the CCE 24 can eithersend an INVITE message to one or more of the plurality of ASs 32 a-32 cfor feature processing for the call or the CCE 24 can send an INVITEmessage to the NRE 33 (i.e. feature processing is not required for thecall) to bypass the plurality of ASs 32 a-32 c and set up the call. TheCCE 24 is further adapted to maintain the call state between the first22 a and the second 22 b communication devices and to generate a calldetail record (CDR) based on instructions received from any one or moreof the plurality of ASs 32 a-32 c.

In the exemplary embodiment, the BEs 26 a-26 d can be provided by LucentCorporation of Murray Hill, N.J. In one embodiment, the BEs 26 a-26 dare adapted to use SIP as the signaling protocol for interfacing withthe CCE 24. Further BE 26 a is adapted to interface to a circuit network(not shown) using an ISDN user port included thereon. The BEs 26 b and26 d are adapted to use SIP as the signaling protocol for interfacingwith the first 34 a and second 34 b PBXs. The BE 26 c is adapted to useH.323 as the signaling protocol for interfacing with the PBX 34 c, viathe Access Gateway (AGW) 31. In the exemplary embodiment, the BEs 26a-26 d may be thought of as a SIP B2BUA because each of the BEs 26 a-26d generates SIP messages as well as receives requests from SIPendpoints, such as the SIP-enabled first 34 a and second 34 b PBXs, andeither processes the requests itself or forwards the requests to the CCE24 for processing. In another embodiment, the BEs 26 a-26 d are adaptedto use SIP as the signaling protocol for interfacing with the AS 32 a-32c when (1) supporting Stimulus Signaling (See: “A Framework for StimulusSignaling in SIP Using Markup”, J. Rosenberg. IETF draft Apr. 24-2002,the subject matter of which is herein incorporated by reference in itsentirety), or (2) supporting communication for services likeClick-to-Dial.

In the exemplary embodiment, the SB 36 can also be provided by LucentCorporation of Murray Hill, N.J. In one embodiment, the SB 36 acts asthe SIP Redirect Server. The SB 36 operates to identify a particularservice request, which is included in the INVITE message received at theSB 36 from the CCE 24. The SB further operates to instruct the CCE 24,via a Redirect message, to redirect the call to one or more of theplurality of ASs 32 a-32 c for service processing. In an embodiment, theSB 36 can identify a particular service requested by the call based onANI or DN information included in the INVITE message received at the SB36 from the CCE 24. In addition, the SB 36 may perform call screeningbased on the Charge Party Station Type (a.k.a. OLI-Originating LineInformation) received in the INVITE message at the SB 36.

After the SB 36 determines a primary AS 32 a, 32 b or 32 c forprocessing a particular call request (as well as a secondary AS 32 a, 32b or 32 c for processing the particular call request), the SB 36generates a SIP Redirect “300 Multiple Choice” message and populates theIP address/Port number combinations of the (primary/secondary) AS 32 a,32 b or 32 c in the Contact headers of the “300 Multiple Choice”message, and sends it to the CCE 24. This approach permits the CCE 24 toquery the secondary AS 32 a, 32 b or 32 c in the event that the primaryAS 32 a, 32 b or 32 c is overloaded or not available to process the callrequest.

In the exemplary embodiment, the plurality of ASs 32 a-32 c can eachinclude a conventional computer server, such as an “NT-Server,” whichcan be provided by Microsoft of Richmond, Wash. or a “Unix SolarisServer,” which can be provided by Sun Micro Systems of Palo Alto, Calif.The ASs 32 a-32 c can be programmed with conventional Web-page interfacesoftware such as: “Visual Basic,” “Java,” “JavaScript,” “HTML/DHTML,”“C++,” “J+,” “Perl,” or “Perlscript,” and “ASP.” The ASs 32 a-32 c caneach further be programmed with an operating system, Web server softwareand Web Application software, such as an e-commerce application andcomputer network interface software. In addition, the ASs 32 a-32 c caneach be programmed with multi-media service software adapted to providea plurality of multi-media services, as is known, such as“Click-to-Dial,” “Video Conferencing,” “Virtual Private Networks,” and“Toll-Free Calling or 800-Service.”

The ASs 32 a-32 c can each be further respectively coupled to databases31 a-31 c, which each contain a service intelligence layer adapted forproviding the plurality of multi-media services described above. Theintelligence layer may include customer logic and data, as well ascommon logic and data that is used by communication devices 22 a, 22 b,as well as a plurality of other communication devices not specificallyshown in FIG. 2.

The NRE 33 also operates as a SIP Redirect Server. The NRE 33 processesINVITE messages received from the CCE 24; performs address resolutionbased on the routing number returned from the AS 32 a-32 c and generatesa Redirect “300 Multiple Choice” message. The NRE 33 populates Redirect300 Multiple Choice message with the IP addresses of one or moredestination BEs 26 a-26 d and sends the Redirect 300 Multiple Choicemessage to the CCE 24. In an embodiment, the NRE 33 can send theRedirect 300 Multiple Choice message to the CCE 24 with a predeterminedhierarchical list of IP addresses corresponding to a predeterminedhierarchical order of BEs 26 a-26 d for processing the call. In thisarrangement, a highest level BE 26 a, 26 b, 26 c or 26 d defined on thelist can receive and process the call and if the highest level BE 26 a,26 b, 26 c or 26 d is unable to process the call or has insufficientresources to do so, the call may be redirected by the CCE 24 to a nextsuccessive BE 26 a, 26 b, 26 c or 26 d defined on the hierarchical list.

The first 22 a and second 22 b communication devices can include aplurality of SIP-enabled devices, such as telephones, personal computersand IP-Private Branch Exchanges (“PBXs”). In addition, the first 22 aand second 22 b communication devices can include a plurality ofSIP-enabled wireless devices, such as cellular telephones, pagers andpersonal digital assistants (“PDAs”).

The MS 30, in the exemplary embodiment, is operative to provide aplurality of predetermined announcements to the communication devices 22a, 22 b and to collect information from the communication devices 22 a,22 b (e.g. caller-entered data). For example, if the caller is requiredto enter digits or a phrase for a Call Prompter service or SDN (SoftwareDefined Network) service, the MS 30 will play the announcement promptingthe caller to enter the required information. The MS 30 also collectsthe information entered by the caller. The MS 30 plays the announcementsto the caller based on the instructions and announcement ID provided inthe second INVITE message. In one embodiment, the announcements caninclude “Service Terminating” announcements or announcements for thecaller to enter an authorization code, account code, or “call-prompter”digits.

Referring now to FIG. 3, which shows an exemplary call flow 100 forprocessing requests for multi-media services that are received at theCCE from the first 22 a and/or second 22 b communication devices. Atstep 110, the CCE receives a first request for a multi-media servicefrom the first 22 a and/or second 22 b communication device. At step120, upon receiving the first request message for the multi-mediaservice, the CCE generates a second request message including attributesof the first request message, which is communicated to the SB 36 forprocessing.

In the exemplary embodiment, the second request message includes anINVITE message having a Content-Type header portion. The Content-Typeheader portion includes a Multi-Purpose Internet Mail Extension (MIME)media type field and a MIME media subtype field. The Content-Type headerportion of the INVITE message describes the content and format of theinformation included in the INVITE message. In an embodiment, theContent-Type header portion includes a MIME media type field having theparameter “application” and a MIME media subtype field having theparameters “vnd.att-advanced-intelligent-features.” These MIME mediatype and subtype fields provide support for advanced intelligentservices such as Toll-Free and Software Defined Network among others. Inthe exemplary embodiment, the INVITE message can include the followinginformation:

INVITE sip:7324204734@sdnas.att.com;user=phone SIP/2.0 Via: SIP/2.0/UDPccenj.att.com:5060 Max-Forwards: 20 From: sip:7324204699@att.com To:<sip:7324204734@att.com> Call-ID: c39h4563-d119a-2995c 2e322238@att.comCSeq: 100 INVITE Accept:application/vnd.att-advanced-intelligent-services Contact:sip:7324204699@mypc.att.com:5060 Content-Type:application/vnd.att-advanced-intelligent-services; boundary=”- - attadvanced services - -” Content-Disposition: session Content-Length:nnn - - att advanced services BEID = be.mtnj.1234 CN = 7324204699;3;1 L= 222 C = 0288;0 CPN = 7324204699;3;1;0;3 CPST = 3 CA =7324204734;3;1 - - att advanced services - -where, the media type parameters of the INVITE message include:

Media Type name: application

Media Subtype name: advanced-intelligence-features

Required parameters: none

Optional parameters: none

Encoding scheme: US-ASCII

Using the above-described media type parameters of the INVITE message,the Content-Type header portion for handling the advanced service of SDNwould be as follows: Content-Type:application/vnd.att-advanced-intelligent-services; charset=US-ASCII;boundary=att-advanced-services. The Content-Type header operates todescribe the data contained in the body of the message so that thereceiving user-agent, such as the SB 36, can identify the contents ofthe message body and process the contents appropriately. The MIME mediatype field declares the general data type while the MIME media subtypefield specifies the specific format for the data type. For example, theMIME media type field of the Content-Type header may include“application/sdp,” which identifies the message body as containinginformation about the Session Description Protocol (SDP), so that an SDPsession may be established between the CCE 24 and the SB 36, forexample.

Further, the MIME media subtype field of the Content-Type header portionincludes the values of “vnd.att-advanced-intelligence-features,” whichimmediately follows the MIME media type field (e.g application) of theContent-Type header. The MIME media subtype field identifies the formatand content of the body portion of the SIP messages as containingparameters for advanced service applications. At step 130, the SB 36receives the INVITE message having the Content-Type header portion,which includes the MIME media subtype field containing the value ofvnd.att-advanced-intelligence-features. Further, the SB 36 processes theINVITE message to generate a Redirect message, which is communicatedback to the CCE 24. Based on the call request related parametersreceived in the message body portion of the INVITE message, the SB 36executes predetermined operations to generate the Redirect message.

At step 140, the CCE 24 receives and processes the Redirect message bygenerating a third request message. The third request message can becommunicated to one or more of the ASs 32 a-32 c for multi-media featureprocessing. After completion of the multi-media feature processing, theone or more ASs 32 a-32 c can communicate with the NRE 33, via the CCE24, for forming a communication path between a calling communicationdevice, such as the first communication device 22 a, and a calledcommunication device, such as the second communication device 22 b. Ifthe CCE 24 determines that multi-media feature processing is notrequired, the CCE 24 can bypass the ASs 32 a-32 c and communicate thethird request message directly to the NRE 33 for forming thecommunication path as described above.

It should be understood that the MIME media subtype field of theContent-Type portion, which includes the values of“vnd.att-.advanced-intelligence-features,” may be incorporated into anumber of other SIP messages, such as Redirect messages, INFO messagesand UPDATE messages. It should be further understood that any one of theSIP messages, which include the MIME media subtype field, can becommunicated between any two or more of the network elements defined onthe multi-media services provider system 10 a.

Information contained in the body portion of the INVITE message (or anyother SIP message incorporating the MIME media subtype field) isidentified by the MIME media subtype field having the values“vnd.att-advanced-intelligence-features,” and is demarcated by a uniqueboundary. For example, the Content-Type header defined by the values orparameters: application/vnd.att-advanced-intelligent-services, includesa unique boundary specified as: -- att-advanced-services--. Informationcontained in the body portion of the INVITE message (or any other SIPmessage incorporating the MIME media subtype field), which is identifiedby the MIME media subtype field having the values or parameters:vnd.att-advanced-intelligence-features, may include sensitive networkand/or customer information. Therefore, during processing of theinformation contained in the body portion of the INVITE message at theCCE 24, for example, the CCE 24 may suppress predetermined parameters ofthe body portion of the INVITE message for security reasons. Forexample, if the CCE 24 terminates an INVITE message to a Border Element26 a-26 d (as opposed to the SB 36) that connects to a customer premisedevice, the CCE 24 may suppress parameters like the Charge Number andCalling Party Station Type. Other parameters like the Calling PartyAddress may also be suppress based on input of the originating user.Note that the security considerations mentioned above are in addition tothe encryption and authentication schemes that SIP provides as astandard part of the protocol.

The Content-Type header having the values of“application/vnd.att-advanced-intelligent-services” can be used in amulti-part message body where two or more different Content-Typescomprise the body. For example, a SIP INVITE message body may have aContent-Type: application/SDP and a Content-Type:application/vnd.att-advanced-intelligent-services.

While various features of the present invention are described herein inconjunction with exemplary embodiments having various components using anumber of protocols, it should be understood that other suitablecomponents and protocols can be used without departing from the presentinvention.

Having thus described at least one illustrative embodiment of theinvention, various alterations, modifications and improvements willreadily occur to those skilled in the art. Such alterations,modifications and improvements are intended to be within the scope andspirit of the invention. Accordingly, the foregoing description is byway of example only and is not intended as limiting. The invention'slimit is defined only in the following claims and the equivalentsthereto. All references and publications cited herein are expresslyincorporated herein by reference in their entirety.

1. A method of processing a request, comprising: receiving a firstrequest message for a multi-media service at a call control element; andprocessing the first request message at the call control element forgenerating a second request message for the multi-media service andincluding a content-type header portion having a media type field and amedia subtype field, wherein the media type field describes a type ofdata, and wherein the media subtype field describes a format of thedata.
 2. The method of claim 1, further comprising: processing thesecond request message at a service broker element for identifying acontent of the second request message, wherein the identifying thecontent of the second request message includes identifying an advancedintelligent service requested by the second request message.
 3. Themethod of claim 1, further comprising: sending the second requestmessage to a service broker element.
 4. The method of claim 3, furthercomprising: receiving a redirect message from the service brokerelement.
 5. The method of claim 4, further comprising: generating athird request message.
 6. The method of claim 5, further comprising:sending the third request message to at least one application server. 7.The method of claim 6, wherein the redirect message comprisesinformation pertaining to the at least one application server.
 8. Themethod of claim 7, wherein the information pertaining to the at leastone application server comprises a primary application server and asecondary application server.
 9. The method of claim 6, furthercomprising: receiving the third request message for the multi-mediaservice by the at least one application server; and processing the thirdrequest message at the at least one application server to identify anadvanced intelligent service.
 10. A non-transitory computer-readablemedium having stored thereon a plurality of instructions, the pluralityof instructions including instructions which, when executed by aprocessor, cause the processor to perform a method for processing arequest, comprising: receiving a first request message for a multi-mediaservice at a call control element; and processing the first requestmessage at the call control element for generating a second requestmessage for the multi-media service and including a content-type headerportion having a media type field and a media subtype field, wherein themedia type field describes a type of data, and wherein the media subtypefield describes a format of the data.
 11. The non-transitorycomputer-readable medium of claim 10, further comprising: processing thesecond request message at a service broker element for identifying acontent of the second request message, wherein the identifying thecontent of the second request message includes identifying an advancedintelligent service requested by the second request message.
 12. Thenon-transitory computer-readable medium of claim 10, further comprising:sending the second request message to a service broker element.
 13. Thenon-transitory computer-readable medium of claim 12, further comprising:receiving a redirect message from the service broker element.
 14. Thenon-transitory computer-readable medium of claim 13, further comprising:generating a third request message.
 15. The non-transitorycomputer-readable medium of claim 14, further comprising: sending thethird request message to at least one application server.
 16. Thenon-transitory computer-readable medium of claim 15, wherein theredirect message comprises information pertaining to the at least oneapplication server.
 17. The non-transitory computer-readable medium ofclaim 16, wherein the information pertaining to the at least oneapplication server comprises a primary application server and asecondary application server.
 18. The non-transitory computer-readablemedium of claim 15, further comprising: receiving the third requestmessage for the multi-media service by the at least one applicationserver; and processing the third request message at the at least oneapplication server to identify an advanced intelligent service.
 19. Acall control element for processing a request, comprising: a processorconfigured to: receive a first request message for a multi-mediaservice; and process the first request message for generating a secondrequest message for the multi-media service and including a content-typeheader portion having a media type field and a media subtype field,wherein the media type field describes a type of data, and wherein themedia subtype field describes a format of the data.
 20. The call controlelement of claim 19, wherein the processor is further configured to sendthe second request message to a service broker element.